Comments
-
Yes, this was occurring before adding the cluster IP addresses to the the DHCP and ARP sections in the SonicWall.
-
The diagram is not accurate on the IP scheme, but shows the issues I'm having. We run on a 255.255.252.0 subnet, 172.16.104.0. These are statically assigned addresses, and there were no static entries in the SonicWall's Statis ARP table. Per SonicWall's support I have added them to the DHCP and ARP sections in the…
-
I think it's happening because there are 3 network connected nodes on the cluster. Each one checks for duplicates of the others, which sends the traffic to the gateway. The gateway is responding back first with the SonicWall MAC, and then the other Nutanix node MAC.
-
This comment was made in error.
-
That sounds how I understand things too, so I don't understand what's going on. I have attached a wireshark screencap where it shows how the SonciWall is responding with its own MAC prior to the Nutanix response. This is the behavior I need to stop from happening. BTW, I appreciate everybody's input on this! EDIT: I see…
-
I uploaded a quick diagram of the process. It's a relatively flat network for this part: everything sits on a single L2 segment and on the same VLAN.
-
I feel I'm not explaining this very well. I will look for or create a diagram here shortly. The process causing the issue is currently: 1) The Nutanix pings its own IP address to look for conflicts. 2) The Sonic Wall (gateway) gets an ARP request as a result. 3) The Sonic Wall replies to the Nutanix ARP request with its…
-
It's a Nutanix cluster. The built-in health checks are what are throwing error flags.